Skip to content

fix(trigger): add size threshold to table bloat trigger#34

Merged
randoneering merged 5 commits into
randoneering:mainfrom
kqr:fix-impractical-table-bloat-trigger
Jul 23, 2026
Merged

fix(trigger): add size threshold to table bloat trigger#34
randoneering merged 5 commits into
randoneering:mainfrom
kqr:fix-impractical-table-bloat-trigger

Conversation

@kqr

@kqr kqr commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Small tables that are frequently rewritten can trivially have > 50 % table bloat even though the absolute size of the bloat is just a few kB. This is the normal, stable, desirable condition for such tables. In those cases, the suggested VACUUM FULL is an incorrect response.

The common solution to this is to add a size threshold to the table bloat trigger. There's no strict guidance for such a threshold, and different sources use different thresholds:

  • pgexperts/pgx_scripts needs 10 MB of table bloat to trigger by default
  • keithf4/pg_bloat_check lists example triggers of 10 MB and 1 GB
  • Heroku's documentation suggests a threshold of 100 MB

This commit is written with a conservative threshold to catch obvious false alarms without deviating too far from the function's earlier behaviour.

Type of Change

  • New health check
  • Bug fix
  • Performance improvement
  • Documentation update
  • Refactoring/code cleanup
  • Breaking change

Related Issues

n/a

Testing

PostgreSQL Version Compatibility

Has this code been tested against the following PostgreSQL versions?

  • PostgreSQL 15
  • PostgreSQL 16
  • PostgreSQL 17
  • PostgreSQL 18

Testing notes:

Very small change and little scope for what could go wrong. It seems to work as expected.

Managed Database Platforms

Has this code been deployed and tested on the following platforms?

  • Amazon RDS for PostgreSQL
  • Google Cloud SQL for PostgreSQL (currently unable to test)
  • Azure Database for PostgreSQL (currently unable to test)
  • Neon
  • Supabase
  • Self-managed PostgreSQL

Platform-specific notes:

Unfortunately not been able to do any testing on managed platforms.

Additional Notes

Confidence Score: 5/5

This looks safe to merge.

No blocking issues found in the changed code. All three SQL variants apply the same threshold, and the predicate compares calculated bloat bytes against a valid PostgreSQL byte-size value.

T-Rex T-Rex Logs

What T-Rex did

  • Observed runtime blockers where connection variables were unset and key tooling like psql, postgres, initdb, pg_ctl, createdb, pg_prove, and Docker were unavailable.
  • Compared paired logs that captured the same execution scope for HEAD^ and the current worktree to validate environment consistency.
  • Executed the Python harness that enforces the size condition with bloat_pct > 50.0, preserves VACUUM FULL advice, tests boundary cases, and checks parity across all three installers.
  • Validated that the harness results align with parity across installers and boundary-case expectations as demonstrated by the artifacts.
  • Compiled and reviewed artifacts that document blocker evidence, paired logs, harness logic, and validation results.

View all artifacts

T-Rex Ran code and verified through T-Rex

Reviews (1): Last reviewed commit: "fix(trigger): add size threshold to tabl..." | Re-trigger Greptile

Small tables that are frequently rewritten can trivially have > 50 % table bloat
even though the absolute size of the bloat is just a few kB. This is the normal,
stable, desirable condition for such tables. In those cases, the suggested
VACUUM FULL is an incorrect response.

The common solution to this is to add a size threshold to the table bloat
trigger. There's no strict guidance for such a threshold, and different sources
use different thresholds:

- pgexperts/pgx_scripts needs 10 MB of table bloat to trigger by default
- keithf4/pg_bloat_check lists example triggers of 10 MB and 1 GB
- Heroku's documentation suggests a threshold of 100 MB

This commit is written with a conservative threshold to catch obvious false
alarms without deviating too far from the function's earlier behaviour.
@kqr
kqr requested a review from randoneering as a code owner July 22, 2026 08:01
Comment thread view_pgFirstAid.sql
@randoneering

Copy link
Copy Markdown
Owner

@greptileai

@randoneering

Copy link
Copy Markdown
Owner

@kqr thank you for the contribution. Edits look good, just don't mind me trying to fix CI 😎. I'll get it resolved and will approve both PRs and merge. Thank you for helping out!

@randoneering randoneering left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good-thank you for the added measure in the bloat check and formatting!

@randoneering
randoneering merged commit 28f9956 into randoneering:main Jul 23, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants